docs(registration): chittycommand Tier-2 registration payload draft (stacked on #110)#111
Conversation
… submission runbook
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
To use Codex here, create a Codex account and connect to github. |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
chittycommand | 57d9a5a | Jun 04 2026, 06:12 AM |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 57d9a5acf0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| { "path": "/api/v1/timeline/:caseId", "method": "GET", "description": "Unified case timeline (facts, deadlines, disputes, docs)", "authenticated": true }, | ||
| { "path": "/api/v1/litigation/synthesize", "method": "POST", "description": "AI fact synthesis from raw notes", "authenticated": true }, | ||
| { "path": "/api/v1/litigation/draft", "method": "POST", "description": "AI email drafting from synthesized facts", "authenticated": true }, | ||
| { "path": "/api/v1/litigation/qc", "method": "POST", "description": "AI risk scan of draft vs source notes", "authenticated": true }, |
There was a problem hiding this comment.
Register the routes that actually exist
These /api/v1/... entries do not match the current Hono mounts I checked: timelineRoutes exposes /api/v1/cases/:caseId/timeline, while the litigation routes are mounted under /api/litigation/*, not /api/v1/litigation/*. Submitting this payload would advertise endpoints that return 404, which undermines the registration inventory and any registry endpoint verification based on it.
Useful? React with 👍 / 👎.
| The actual injection uses `op run` per the operator manifest. The template below shows the request shape — do NOT run it verbatim with raw env vars. | ||
|
|
||
| ```bash | ||
| jq '.registrationToken="$CHITTY_REGISTER_TOKEN" | .service.chittyId="$NEW_CHITTYID"' \ |
There was a problem hiding this comment.
Expand env values before sending jq output
This jq expression writes the literal strings $CHITTY_REGISTER_TOKEN and $NEW_CHITTYID into the JSON body; I confirmed jq does not expand shell variables inside a quoted filter. Even when op run provides the environment, the Authorization header may use the real token but the submitted registrationToken and service.chittyId fields remain invalid unless the command uses --arg/env.* or an equivalent injection mechanism.
Useful? React with 👍 / 👎.
| curl -sS https://command.chitty.cc/health | jq . | ||
| ``` | ||
|
|
||
| Must return the real-dependency probe JSON shape — fields for `db`, `chittyconnect`, and `daemon` heartbeat must reflect actual probed state. A static `{"status":"ok"}` response is a regression and blocks submission per the global "no fake/non-working endpoints" rule. |
There was a problem hiding this comment.
Align the health preflight with the deployed endpoint
This preflight currently blocks submission because src/index.ts still serves /health as a static { status, service, version, timestamp } response and does not include the db, chittyconnect, or daemon fields required here. Since the runbook says the operator should submit after these stacked PRs merge, either the health implementation needs to be updated in the stack or this requirement will make the documented submission path fail closed every time.
Useful? React with 👍 / 👎.
| jq '.registrationToken="$CHITTY_REGISTER_TOKEN" | .service.chittyId="$NEW_CHITTYID"' \ | ||
| docs/registration/chittycommand-registration-payload.json | \ | ||
| curl -sS -X POST https://register.chitty.cc/api/v1/register \ | ||
| -H "Authorization: Bearer $CHITTY_REGISTER_TOKEN" \ |
There was a problem hiding this comment.
Avoid putting the bearer token in curl argv
If the operator follows this template under op run, the shell expands $CHITTY_REGISTER_TOKEN into the curl -H argument before curl starts, which puts the bearer in the process command line visible to local process inspection/logging. That contradicts the runbook’s guarantee that the operator path never handles the bearer directly; use a brokered request or a mechanism that does not place the secret in argv.
Useful? React with 👍 / 👎.
…rface (#110) * docs(charter,chitty,claude): reclassify Tier 5 → Tier 2 platform with Tier-5 surface; add meta endpoints and dependencies Stacked follow-on to PR #106 (ADR-001 + executor registry). Documentation-only PR that brings the compliance triad and `/api/v1/status` in line with the ADR-001 amendment that landed on `feat/meta-executors-registry`. CHARTER.md / CHITTY.md / CLAUDE.md - Canonical phrasing: "Tier 2 (Platform) with Tier-5 dashboard surface" everywhere a tier is declared. - RY (Authority) row rewritten to reflect sovereignty enforcement + intent execution + multi-source ingest. No longer a pure consumer. - API contract gains the one real new endpoint introduced by #106: POST /api/v1/intents/:id/execute. Per the global no-fake-endpoints rule, the planned intent CRUD (POST /api/v1/intents, GET .../:id, GET ..., GET /api/v1/executors) is NOT documented here because it isn't implemented; it will be added when the routes are. - New Executor Registry table with canonical URI chittycanon://core/services/chittycommand/executors/{intent_type}. Lists the one executor that actually self-registers today (update_obligation_status). mercury_payment is flagged as a tracked future executor with REAL-MONEY constraints (fresh autonomous sovereignty, USD 500 per-intent cap) and explicitly NOT documented as registered. - New Cluster Runtime section: daemon is launchd/systemd, NOT a Worker; per-node L-type ChittyIDs register as sub-channels via agent.chitty.cc/api/v1/channels, NOT in the main ChittyRegister payload. - Dependencies expanded: ChittyTrust, ChittyID, chittyagent-orchestrator, chittyagent-tasks, chittyagent-ch1tty added. ChittyConnect entry expanded to call out ContextConsciousness + MemoryCloude (forever context) and sensitive-intent secret brokerage. - Compliance section flags the ChittyID re-mint as required operator action (T → P-Synthetic) and explicitly defers /health real-probes and tail_consumers wiring to separate PRs. - MCP tool count reconciled to 50 (CLAUDE.md was already correct; CHARTER/ CHITTY updated from stale "48"). src/index.ts - /api/v1/status returns tier: 2 plus tierSurface phrasing and a meta.endpoints array listing the registered intent-execute route. No other route, middleware, or handler touched. src/routes/meta.ts - /api/v1/canon returns tier: 2 + tierSurface so the public canon view matches /status and the docs. Same handler signature; no behavior change. Not in this PR (deferred): - Real-dependency /health probes (separate PR). - tail_consumers wiring to chittytrack (separate observability PR). - ChittyRegister payload submission (operator action; blocked on re-mint). - Re-mint of service ChittyID as P-Synthetic (operator action). - Intent CRUD endpoints and /api/v1/executors enumeration (future PRs). Compliance coverage: - Addresses: tier reclassification, RY language, meta endpoint surface, executor URI registry, dependency expansion, cluster sub-channel declaration (items 1, 4, 5, 7, 8 of the registration-readiness audit). - Remaining (out of scope): registration submission (item 2, operational), real /health (item 3, separate PR), tail_consumers (item 6, separate PR), P-type ChittyID re-mint (item 9, operator action). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(charter): clarify Worker vs daemon runtime split in Classification Addresses Codex P2 on PR #110: the previous wording said the Tier-2 platform and Tier-5 surface 'both run from the same worker', which contradicts the Cluster Runtime section stating daemon/ runs as a supervised launchd/systemd process, not as a Worker. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(registration): draft chittycommand Tier-2 registration payload + submission runbook (#111) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: chitcommit <noreply@chitty.cc>
…rface (#110) * docs(charter,chitty,claude): reclassify Tier 5 → Tier 2 platform with Tier-5 surface; add meta endpoints and dependencies Stacked follow-on to PR #106 (ADR-001 + executor registry). Documentation-only PR that brings the compliance triad and `/api/v1/status` in line with the ADR-001 amendment that landed on `feat/meta-executors-registry`. CHARTER.md / CHITTY.md / CLAUDE.md - Canonical phrasing: "Tier 2 (Platform) with Tier-5 dashboard surface" everywhere a tier is declared. - RY (Authority) row rewritten to reflect sovereignty enforcement + intent execution + multi-source ingest. No longer a pure consumer. - API contract gains the one real new endpoint introduced by #106: POST /api/v1/intents/:id/execute. Per the global no-fake-endpoints rule, the planned intent CRUD (POST /api/v1/intents, GET .../:id, GET ..., GET /api/v1/executors) is NOT documented here because it isn't implemented; it will be added when the routes are. - New Executor Registry table with canonical URI chittycanon://core/services/chittycommand/executors/{intent_type}. Lists the one executor that actually self-registers today (update_obligation_status). mercury_payment is flagged as a tracked future executor with REAL-MONEY constraints (fresh autonomous sovereignty, USD 500 per-intent cap) and explicitly NOT documented as registered. - New Cluster Runtime section: daemon is launchd/systemd, NOT a Worker; per-node L-type ChittyIDs register as sub-channels via agent.chitty.cc/api/v1/channels, NOT in the main ChittyRegister payload. - Dependencies expanded: ChittyTrust, ChittyID, chittyagent-orchestrator, chittyagent-tasks, chittyagent-ch1tty added. ChittyConnect entry expanded to call out ContextConsciousness + MemoryCloude (forever context) and sensitive-intent secret brokerage. - Compliance section flags the ChittyID re-mint as required operator action (T → P-Synthetic) and explicitly defers /health real-probes and tail_consumers wiring to separate PRs. - MCP tool count reconciled to 50 (CLAUDE.md was already correct; CHARTER/ CHITTY updated from stale "48"). src/index.ts - /api/v1/status returns tier: 2 plus tierSurface phrasing and a meta.endpoints array listing the registered intent-execute route. No other route, middleware, or handler touched. src/routes/meta.ts - /api/v1/canon returns tier: 2 + tierSurface so the public canon view matches /status and the docs. Same handler signature; no behavior change. Not in this PR (deferred): - Real-dependency /health probes (separate PR). - tail_consumers wiring to chittytrack (separate observability PR). - ChittyRegister payload submission (operator action; blocked on re-mint). - Re-mint of service ChittyID as P-Synthetic (operator action). - Intent CRUD endpoints and /api/v1/executors enumeration (future PRs). Compliance coverage: - Addresses: tier reclassification, RY language, meta endpoint surface, executor URI registry, dependency expansion, cluster sub-channel declaration (items 1, 4, 5, 7, 8 of the registration-readiness audit). - Remaining (out of scope): registration submission (item 2, operational), real /health (item 3, separate PR), tail_consumers (item 6, separate PR), P-type ChittyID re-mint (item 9, operator action). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(charter): clarify Worker vs daemon runtime split in Classification Addresses Codex P2 on PR #110: the previous wording said the Tier-2 platform and Tier-5 surface 'both run from the same worker', which contradicts the Cluster Runtime section stating daemon/ runs as a supervised launchd/systemd process, not as a Worker. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(registration): draft chittycommand Tier-2 registration payload + submission runbook (#111) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: chitcommit <noreply@chitty.cc>
Stacked on #110
This PR is stacked on top of PR #110 (
docs/tier-2-reclassification). It must merge AFTER #110 lands onmain. Do not squash-merge intomainuntil #110 is in.What this adds
docs/registration/chittycommand-registration-payload.json— draft registration payload forregister.chitty.cc, shaped against the realServiceRegistrationSchemainchittyregistry/src/types/index.ts.docs/registration/SUBMISSION_RUNBOOK.md— operator runbook for the submission step (pre-flight, substitutions, verification, rollback).Schema source
The payload was drafted against the canonical schema at
chittyos/chittyregistry→src/types/index.ts→ServiceRegistrationSchema. No synthesized or guessed fields.Placeholders substituted at submission time
Two values are intentionally left as placeholder strings in the committed JSON. Both are resolved at submission time via ChittyConnect (Chico), never pasted into chat or committed:
<<CHITTY_REGISTER_TOKEN>>— bearer forregister.chitty.cc, resolved via 1Password → CF Secrets through ChittyConnect.<<PENDING_P_SYNTHETIC_CHITTYID>>— newly minted P-Synthetic ChittyID. The previous ID03-1-USA-3846-T-2602-0-57is deprecated (T-type encoding invalid for a sovereign actor).Explicitly NOT in this PR
register.chitty.cc.CHARTER.md/CHITTY.md/CLAUDE.md— those are docs: reclassify Tier 5 -> Tier 2 (Platform) with Tier-5 dashboard surface #110's lane.Next step after merge
After #110 + this PR are on
main, the operator runs the submission perSUBMISSION_RUNBOOK.md, then opens a follow-up PR to record the registration verification response in CHARTER.md.